Headless resilient backup and restore software ecosystem

ABSTRACT

Provided are techniques for a headless resilient backup and restore software ecosystem. At a first backup server of a plurality of backup servers, a connection request is received. At the first backup server, a second backup server is identified by: determining a backup server score for each of the plurality of backup servers based on identification factors comprising historical client latency, scheduled backup server workload, and whether the metadata is already cached on any of the plurality of backup servers and identifying the second backup server as having a lowest backup server score. The identification of the second backup server is returned.

FIELD

Embodiments of the invention relate to a headless resilient backup andrestore software ecosystem.

BACKGROUND

A backup environment includes clients accessing server computers fordata. The same data may be stored in different server computers.However, existing backup infrastructure designs use flawed and limitedapproaches to scaling the backup environment.

One conventional approach relies on shifting to larger hardware in a“scale up” technique, which does not translate well into moderncommodity based computing environments, such as those used by publiccloud providers.

For those environments that do scale out, another conventional approachrelies on a head server computer that centrally handles the schedulingand distribution of work among the server computers (e.g., requests fromthe clients), but, if the head server computer becomes unavailable, theentire backup environment becomes unusable.

SUMMARY

Provided is a computer program product for a headless resilient backupand restore software ecosystem. The computer program product comprises acomputer readable storage medium having program code embodied therewith,the program code executable by at least one processor to perform:receiving, at a first backup server of a plurality of backup servers, aconnection request; identifying, at the first backup server, a secondbackup server by: determining a backup server score for each of theplurality of backup servers based on identification factors comprisinghistorical client latency, scheduled backup server workload, and whethermetadata is already cached on any of the plurality of backup servers,and identifying the second backup server as having a lowest backupserver score; and returning identification of the second backup server.

Provided is a computer system for a headless resilient backup andrestore software ecosystem. The computer system comprises one or moreprocessors, one or more computer-readable memories and one or morecomputer-readable, tangible storage devices; and program instructions,stored on at least one of the one or more computer-readable, tangiblestorage devices for execution by at least one of the one or moreprocessors via at least one of the one or more memories, to performoperations comprising: receiving, at a first backup server of aplurality of backup servers, a connection request; identifying, at thefirst backup server, a second backup server by: determining a backupserver score for each of the plurality of backup servers based onidentification factors comprising historical client latency, scheduledbackup server workload, and whether metadata is already cached on any ofthe plurality of backup servers, and identifying the second backupserver as having a lowest backup server score; and returningidentification of the second backup server.

Provided is a method for a headless resilient backup and restoresoftware ecosystem. The method comprises: receiving, at a first backupserver of a plurality of backup servers, a connection request;identifying, at the first backup server, a second backup server by:determining a backup server score for each of the plurality of backupservers based on identification factors comprising historical clientlatency, scheduled backup server workload, and whether metadata isalready cached on any of the plurality of backup servers, andidentifying the second backup server as having a lowest backup serverscore; and returning identification of the second backup server.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

Referring now to the drawings in which like reference numbers representcorresponding parts throughout:

FIG. 1 illustrates, in a block diagram, a backup and restore softwareecosystem in accordance with certain embodiments.

FIG. 2 illustrates, in a flow chart, operations for a client to checkfor job information in accordance with certain embodiments.

FIG. 3 illustrates, in a flow chart, operations for a client to attempta backup operation in accordance with certain embodiments.

FIG. 4 illustrates, in a flow chart, operations for a client to attempta restore operation in accordance with certain embodiments.

FIG. 5 illustrates, in a flow chart, operations for pre-fetchingmetadata in accordance with certain embodiments.

FIG. 6 illustrates, in a flow chart, operations for identifying a backupserver in accordance with certain embodiments.

FIG. 7 illustrates a computing architecture in which the components ofFIG. 1 may be implemented.

FIG. 8 illustrates a cloud computing environment according to anembodiment of the present invention.

FIG. 9 illustrates abstraction model layers according to an embodimentof the present invention.

DETAILED DESCRIPTION

The descriptions of the various embodiments of the present inventionhave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

With embodiments, a backup and restore software ecosystem includes thefollowing components: backup servers, metadata caches, metadatarepositories, and common storage. With embodiments, the backup andrestore software ecosystem optionally includes backup data storage,which may be cache. The common storage stores the authoritative copy ofbackup data (i.e., objects), while the backup data storage cachestemporary copies of the backup data for performance improvement. Themetadata repositories and the metadata cache store metadata. The backupservers respond to requests from clients regarding objects (e.g., movingobjects, storing new objects, deleting existing objects, backing up newobjects, retrieving/restoring objects, etc.). Each of the backup servershas its own metadata cache and optionally its own backup data storage.

Thus, the backup and restore software ecosystem encompasses bothmetadata storage and backup data storage comprised of multiple computeand storage resources. The backup and restore software ecosystem is ableto function without relying on any one central component (i.e., it is“headless”). The backup and restore software ecosystem also grows andshrinks based on demand by adding or removing components of a given typewithout having to bring down the entire backup and restore softwareecosystem. The backup and restore software ecosystem also allows everycomponent to actively contribute to the load being handled by the backupand restore software ecosystem, and there are no passive componentsrequired for redundancy.

FIG. 1 illustrates, in a block diagram, a backup and restore softwareecosystem 100 in accordance with certain embodiments. Clients 101, 102,103, 104, 105, 106 are coupled to the backup and restore softwareecosystem 100.

The backup and restore software ecosystem 100 includes:

-   -   backup servers 120, 121, 122, 123, 124, 125, 126;    -   metadata cache 140, 141, 142, 143, 144, 145, 146;    -   backup data storage 160, 161, 162, 163, 164, 165, 166;    -   metadata repositories 180, 182, 184; and    -   common storage 190.

In FIG. 1, backup server 120 is coupled to metadata cache 140 and backupdata storage 160; backup server 121 is coupled to metadata cache 141 andbackup data storage 161; backup server 122 is coupled to metadata cache142 and backup data storage 162; backup server 123 is coupled tometadata cache 143 and backup data storage 163; backup server 124 iscoupled to metadata cache 144 and backup data storage 164; backup server125 is coupled to metadata cache 145 and backup data storage 165; andbackup server 126 is coupled to metadata cache 146 and backup datastorage 166. Each of the backup servers 120, 121, 122, 123, 124, 125,126 may store objects in common storage 190 and may store metadata inmetadata repositories 180, 182, 184. Also, each of the backup servers120, 121, 122, 123, 124, 125, 126 knows which jobs are being executed onwhich backup servers 120, 121, 122, 123, 124, 125, 126. Metadata cache140 includes pre-fetched metadata for client 1.

Clients 101, 102, 103, 104, 105, 106 may issue request about the objectsto any of the backup servers 120, 121, 122, 123, 124, 125, 126.

With embodiments, metadata for a given client 101, 102, 103, 104, 105,106 may be placed on at least two separate metadata repositories 180,182, 184. For example, metadata for client 1 101 is stored on metadatarepositories 180, 182; metadata for client 2 102 is stored on metadatarepositories 180, 184; metadata for client 3 103 is stored on metadatarepositories 182, 184; metadata for client 4 104 is stored on metadatarepositories 180, 182; metadata for client 5 105 is stored on metadatarepositories 180, 184; metadata for client 6 106 is stored on metadatarepositories 182, 184.

The number of metadata repositories 180, 182, 184 to store the metadatafor a given client 101, 102, 103, 104, 105, 106 is determined by theamount of redundancy desired. With embodiments, a system administratormay set this number.

A client may periodically check with the backup and restore softwareecosystem 100 for outstanding jobs. FIG. 2 illustrates, in a flow chart,operations for a client to check for job information in accordance withcertain embodiments. Control begins at block 200 with the client sendinga connection request to any one of the backup servers asking foridentification of a data server to obtain job information.

In block 202, the backup server receiving the request identifies abackup server to provide the job information and sends a response to theclient identifying a backup server. In block 204, the client receivesthe response identifying a backup server. That is, any backup serverthat receives the request from the client is able to identify a backupserver to respond to the client request. This allows for load balancingamong the backup servers in a “headless” backup and restore softwareecosystem 100 (i.e., unlike conventional systems, there is no need forone of the backup servers to be the “head” in charge of load balancing).

In block 206, the client sends a request to the identified backup serverto request the job information. In block 208, the identified backupserver sends a response to the client. In block 210, the client receivesa response of: 1) the job information; 2) an indication that there is nojob information currently available (and to check back later), or 3) anindication to start a backup job. FIG. 3 illustrates, in a flow chart,operations for a client to attempt a backup operation (i.e., to backupobjects from the client to the backup server, for storage in the commonstore) in accordance with certain embodiments. Control begins at block300 with the client sending a connection request to any one of thebackup servers asking for identification of a data server to start abackup job.

In block 302, the backup server receiving the request identifies abackup server to provide the job information and sends a response to theclient identifying a backup server. In block 304, the client receivesthe response identifying a backup server. That is, any backup serverthat receives the request from the client is able to identify a backupserver to respond to the client request. This allows for load balancingamong the backup servers in a “headless” backup and restore softwareecosystem 100.

In block 306, the client sends a request to the identified backup serverto start the backup job. In block 308, the identified backup serverbegins to pre-fetch metadata for the client into the metadata cache (forthat backup server), if the metadata is not already present. In block310, the identified backup server performs the backup job, with themetadata repositories for the client being updated as writes arecompleted to the common storage, with the optional backup data storageacting as a performance buffer. That is, the objects from the clientbeing backed up may be temporarily stored in the backup data storage,before being stored in the common storage. In block 312, the identifiedbackup server provides the client with a list of backup severs for usefor future (subsequent) requests. With embodiments, this is an updatedlist of all backup servers for future connection attempts. For example,if a backup server is no longer available or a new backup server isavailable, the updated list will reflect this.

FIG. 4 illustrates, in a flow chart, operations for a client to attempta restore operation (i.e., to restore objects from the backup server(i.e., from the common store) to the client) in accordance with certainembodiments. Control begins at block 400 with the client sending aconnection request to any one of the backup servers asking foridentification of a data server to start a restore job. In block 402,the backup server receiving the request identifies a backup server toprovide the job information and sends a response to the clientidentifying a backup server. In block 404, the client receives theresponse identifying a backup server. That is, any backup server thatreceives the request from the client is able to identify a backup serverto respond to the client request. This allows for load balancing amongthe backup servers in a “headless” backup and restore software ecosystem100.

In block 406, the client sends a request to the identified backup serverto start the restore job. In block 408, the identified backup serverbegins to pre-fetch metadata for the client into the metadata cache (forthat backup server), if the metadata is not already present. In block410, the identified backup server performs the restore job, with themetadata repositories for the client being updated as writes arecompleted from the common storage, with the optional backup data storageacting as a performance buffer. That is, the objects from the commonstore being restored may be temporarily stored in the backup datastorage, before being returned to the client. Embodiments may pre-fetchto the backup data storage to improve performance. In block 412, theidentified backup server provides the client with a list of backupsevers for use for future requests. With embodiments, this is an updatedlist of all backup servers for future connection attempts. For example,if a backup server is no longer available or a new backup server isavailable, the updated list will reflect this.

FIG. 5 illustrates, in a flow chart, operations for pre-fetchingmetadata in accordance with certain embodiments. With embodiments, eachbackup server performs the operations of FIG. 5. Control begins at block500, with each of the backup servers periodically determining a backupserver pre-fetch score. In block 502, at each of the backup servers, thebackup server pre-fetch score of each of the backup servers is summed upto generate a total pre-fetch score. In block 504, at each of the backupservers, in response to determining that the total pre-fetch score doesnot exceed a maximum threshold, a backup server having a lowest, backupserver pre-fetch score is identified. In block 506, the identifiedbackup server pre-fetches metadata. With embodiments, the maximumthreshold may be adjusted by a system administrator. That is, if thetotal pre-fetch score exceeds a maximum threshold, metadata is notpre-fetched, otherwise, metadata is pre-fetched on the backup serverhaving the lowest, backup server pre-fetch score.

With embodiments, each backup server determines a client pre-fetch scorefor each client and then sums up those client pre-fetch scores todetermine the total pre-fetch score. With embodiments each of the backupservers periodically evaluates, for each client that interacts with thatbackup server, a list of upcoming scheduled jobs and uses historicalclient latency, scheduled backup server workloads of that backup server,and past reliability of the client to determine the pre-fetch score.Thus, the pre-fetch score for a client is based on pre-fetch factorscomprising historical client latency, scheduled backup server workloads,and failure percentage.

With embodiments, each backup server uses the following formulas:

client pre-fetch score=(historical client latency*weight1)+(scheduledbackup server workload*weight2)+((1−failure percentage)*weight3)

backup server pre-fetch score=sum of client pre-fetch scores

total pre-fetch score=sum of backup server prefetch scores

Historical client latency may be described as a measured round trip timeof the client for the past several times that the client has interactedwith the backup server. The scheduled backup server workload may bedescribed as the scheduled backup server workload of the backup servergenerating the pre-fetch score. The scheduled backup server workload mayalso be referred to as a current backup server workload. The failurepercentage may be described as a measure of the reliability of theclient (i.e., the backup server does not want to pre-fetch for a clientthat hasn't talked to the backup server for a period of time (e.g.,during several past scheduled windows of time)). With embodiments,weights may be used to adjust the pre-fetch factors in the formula. Withembodiments, any group of weight1, weight2, and weight3 may have thesame value or different values. Also, the weights may be adjusted by asystem administrator.

FIG. 6 illustrates, in a flow chart, operations for identifying a backupserver in accordance with certain embodiments. Control begins at block600 with a backup server of a plurality of backup servers receiving aclient request for a connection. In block 602, the backup serverdetermines a backup server score for each backup server of the pluralityof backup servers based on identification factors comprising historicalclient latency, scheduled backup server workload, and whether themetadata is already cached on any backup servers. In block 604, thebackup server identifies a backup server of the plurality of backupservers with a lowest backup server score. In block 606, the backupserver returns the identified backup server to the client.

With embodiments, the backup server is identified based on severalweighted identification factors x, y, and z as follows:

-   -   x=historical client latency of each client of the backup server        (where x may be determined by summing up the historical client        latency of each client that accesses the backup server);    -   y=scheduled backup server workload; and    -   z=whether metadata for any client is already cached for the        backup server (i.e., pre-fetched for scheduled jobs).

With embodiments, each of the identification factors x, y, and z isevaluated individually to generate a score that is adjusted by a weight.With embodiments, each identification factor has a weight associatedwith it (a, b, and c) such that the total score “S” for a given backupserver is:

S=xa+yb+zc

The scores for each backup server are compared to identify the backupserver with the lowest score, which is selected to process a job for theclient.

With embodiments, any group of weight a, weight b, and weight c may havethe same value or different values. Also, the weights may be adjusted bya system administrator.

With embodiments, if one of the backup servers becomes unavailable, thenany of the other backup servers is able to determine that a backupserver is unavailable and execute the jobs that the backup server hadbeen executing. With embodiments, the backup servers share theirscheduling information with each other to enable one backup server totake over jobs for another backup server.

Thus, embodiments provide a backup and restore software ecosystem 100for managing and performing data backup and restore operations.Embodiments dynamically manages a set of backup servers to activate andde-activate backup servers as needed. In cloud environments, it ispossible to spin up and spin down additional servers in under a few(e.g., 5) minutes. Using this capability, embodiments may quickly adjustthe number of backup servers to match peak loads, while de-activatingbackup servers during low demand to minimize costs. Embodiments alsoassign a specific backup server to a client request based onidentification factors representing backup and restore softwareecosystem 100 performance.

Embodiments avoid having a central scheduler/balancer, which representsa single point of failure, by providing a headless backup and restoresoftware ecosystem 100 in which each of the backup servers performs loadbalancing. Also, the client may request a connection from any of thebackup servers, which avoids the client having to always work with aparticular backup server.

With embodiments, the backup servers may be dynamically created andremoved based on load requirements.

Embodiments enable managing and performing data backup operations byassigning a specific backup server to a client request based on certainsystem performance factors and determining pre-fetch of metadata byevaluating a list of upcoming jobs/data and historical client latency.

FIG. 7 illustrates a computing architecture in which the components ofFIG. 1 may be implemented. In certain embodiments, the storagecontroller 70 and/or hosts 190 may implement computer architecture 700.

Computer system/server 702 may be described in the general context ofcomputer system executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 702 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 7, the computer system/server 702 is shown in the formof a general-purpose computing device. The components of computersystem/server 702 may include, but are not limited to, one or moreprocessors or processing units 704, a system memory 706, and a bus 708that couples various system components including system memory 706 toprocessor 704. Bus 708 represents one or more of any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, andnot limitation, such architectures include Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnects (PCI) bus.

Computer system/server 702 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 702, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 706 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 711 and/or cachememory 712. Computer system/server 702 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 713 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 708 by one or more datamedia interfaces. As will be further depicted and described below,memory 706 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 714, having a set (at least one) of program modules 716,may be stored in memory 706 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. The components of the computer 702 may be implemented asprogram modules 716 which generally carry out the functions and/ormethodologies of embodiments of the invention as described herein. Thesystems of FIG. 1 may be implemented in one or more computer systems702, where if they are implemented in multiple computer systems 702,then the computer systems may communicate over a network.

Computer system/server 702 may also communicate with one or moreexternal devices 718 such as a keyboard, a pointing device, a display720, etc.; one or more devices that enable a user to interact withcomputer system/server 702; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 702 to communicate withone or more other computing devices. Such communication can occur viaInput/Output (I/O) interfaces 722. Still yet, computer system/server 702can communicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 724. As depicted, network adapter 724communicates with the other components of computer system/server 702 viabus 708. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 702. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, and “one embodiment” mean “one or more (but not all)embodiments of the present invention(s)” unless expressly specifiedotherwise.

The terms “including”, “comprising”, “having” and variations thereofmean “including but not limited to”, unless expressly specifiedotherwise.

The enumerated listing of items does not imply that any or all of theitems are mutually exclusive, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required. Onthe contrary a variety of optional components are described toillustrate the wide variety of possible embodiments of the presentinvention.

When a single device or article is described herein, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described herein (whether ornot they cooperate), it will be readily apparent that a singledevice/article may be used in place of the more than one device orarticle or a different number of devices/articles may be used instead ofthe shown number of devices or programs. The functionality and/or thefeatures of a device may be alternatively embodied by one or more otherdevices which are not explicitly described as having suchfunctionality/features. Thus, other embodiments of the present inventionneed not include the device itself.

The foregoing description of various embodiments of the invention hasbeen presented for the purposes of illustration and description. It isnot intended to be exhaustive or to limit the invention to the preciseform disclosed. Many modifications and variations are possible in lightof the above teaching. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto. The above specification, examples and data provide acomplete description of the manufacture and use of the composition ofthe invention. Since many embodiments of the invention can be madewithout departing from the spirit and scope of the invention, theinvention resides in the claims herein after appended.

Cloud Embodiments

It is to be understood that although this disclosure includes a detaileddescription on cloud computing, implementation of the teachings recitedherein are not limited to a cloud computing environment. Rather,embodiments of the present invention are capable of being implemented inconjunction with any other type of computing environment now known orlater developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported, providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure that includes anetwork of interconnected nodes.

Referring now to FIG. 8, illustrative cloud computing environment 850 isdepicted. As shown, cloud computing environment 850 includes one or morecloud computing nodes 810 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 854A, desktop computer 854B, laptop computer 854C,and/or automobile computer system 854N may communicate. Nodes 810 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof. This allows cloud computing environment 850 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computingdevice. It is understood that the types of computing devices 854A-Nshown in FIG. 8 are intended to be illustrative only and that computingnodes 810 and cloud computing environment 850 can communicate with anytype of computerized device over any type of network and/or networkaddressable connection (e.g., using a web browser).

Referring now to FIG. 9, a set of functional abstraction layers providedby cloud computing environment 850 (FIG. 8) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 9 are intended to be illustrative only and embodiments of theinvention are not limited thereto. As depicted, the following layers andcorresponding functions are provided:

Hardware and software layer 960 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 961;RISC (Reduced Instruction Set Computer) architecture based servers 962;servers 963; blade servers 964; storage devices 965; and networks andnetworking components 966. In some embodiments, software componentsinclude network application server software 967 and database software968.

Virtualization layer 970 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers971; virtual storage 972; virtual networks 973, including virtualprivate networks; virtual applications and operating systems 974; andvirtual clients 975.

In one example, management layer 980 may provide the functions describedbelow. Resource provisioning 981 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 982provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may include applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 983 provides access to the cloud computing environment forconsumers and system administrators. Service level management 984provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 985 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 990 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 991; software development and lifecycle management 992;virtual classroom education delivery 993; data analytics processing 994;transaction processing 995; and headless resilient backup and restoresoftware ecosystem.

Thus, in certain embodiments, software or a program, implementingheadless resilient backup and restore software ecosystem in accordancewith embodiments described herein, is provided as a service in a cloudinfrastructure.

In certain embodiments, the components of the backup and restoresoftware ecosystem 100 are part of a cloud infrastructure. In otherembodiments, the components of the backup and restore software ecosystem100 are not part of a cloud infrastructure.

Thus, in certain embodiments, a plurality of backup servers are nodes ina cloud infrastructure that includes metadata cache for each of theplurality of backup servers, backup data storage for each of theplurality of backup servers, metadata repositories shared by each of theplurality of backup servers, and common storage shared by each of theplurality of backup servers.

ADDITIONAL EMBODIMENT DETAILS

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is:
 1. A computer program product, the computer programproduct comprising a computer readable storage medium having programcode embodied therewith, the program code executable by at least oneprocessor to perform: receiving, at a first backup server of a pluralityof backup servers, a connection request; identifying, at the firstbackup server, a second backup server by: determining a backup serverscore for each of the plurality of backup servers based onidentification factors comprising historical client latency, scheduledbackup server workload, and whether metadata is already cached on any ofthe plurality of backup servers; and identifying the second backupserver as having a lowest backup server score; and returningidentification of the second backup server.
 2. The computer programproduct of claim 1, wherein the identification factors are weighted. 3.The computer program product of claim 1, wherein the program code isexecutable by at least one processor to perform: at each of theplurality of backup servers, periodically determining a pre-fetch scorebased on pre-fetch factors comprising the historical client latency, thescheduled backup server workload, and failure percentage; and inresponse to determining that the pre-fetch score does not exceed amaximum threshold on each of the plurality of backup servers,pre-fetching metadata on a backup server having a lowest pre-fetchscore.
 4. The computer program product of claim 1, wherein the metadatais pre-fetched from a metadata repository to metadata cache.
 5. Thecomputer program product of claim 1, wherein the second backup serverprovides a client with a list of backup severs for use for futurerequests.
 6. The computer program product of claim 1, wherein theplurality of backup servers are nodes in a cloud infrastructure thatincludes a metadata cache for each of the plurality of backup servers,backup data storage for each of the plurality of backup servers,metadata repositories shared by each of the plurality of backup servers,and common storage shared by each of the plurality of backup servers. 7.A computer system, comprising: one or more processors, one or morecomputer-readable memories and one or more computer-readable, tangiblestorage devices; and program instructions, stored on at least one of theone or more computer-readable, tangible storage devices for execution byat least one of the one or more processors via at least one of the oneor more memories, to perform operations comprising: receiving, at afirst backup server of a plurality of backup servers, a connectionrequest; identifying, at the first backup server, a second backup serverby: determining a backup server score for each of the plurality ofbackup servers based on identification factors comprising historicalclient latency, scheduled backup server workload, and whether metadatais already cached on any of the plurality of backup servers; andidentifying the second backup server as having a lowest backup serverscore; and returning identification of the second backup server.
 8. Thecomputer system of claim 7, wherein the identification factors areweighted.
 9. The computer system of claim 7, wherein the operationsfurther comprise: at each of the plurality of backup servers,periodically determining a pre-fetch score based on pre-fetch factorscomprising the historical client latency, the scheduled backup serverworkload, and failure percentage; and in response to determining thatthe pre-fetch score does not exceed a maximum threshold on each of theplurality of backup servers, pre-fetching metadata on a backup serverhaving a lowest pre-fetch score.
 10. The computer system of claim 7,wherein the metadata is pre-fetched from a metadata repository tometadata cache.
 11. The computer system of claim 7, wherein the secondbackup server provides a client with a list of backup severs for use forfuture requests.
 12. The computer system of claim 7, wherein theplurality of backup servers are nodes in a cloud infrastructure thatincludes a metadata cache for each of the plurality of backup servers,backup data storage for each of the plurality of backup servers,metadata repositories shared by each of the plurality of backup servers,and common storage shared by each of the plurality of backup servers.13. A method, comprising: receiving, at a first backup server of aplurality of backup servers, a connection request; identifying, at thefirst backup server, a second backup server by: determining a backupserver score for each of the plurality of backup servers based onidentification factors comprising historical client latency, scheduledbackup server workload, and whether metadata is already cached on any ofthe plurality of backup servers; and identifying the second backupserver as having a lowest backup server score; and returningidentification of the second backup server.
 14. The method of claim 13,wherein the identification factors are weighted.
 15. The method of claim13, wherein the program code is executable by at least one processor toperform: at each of the plurality of backup servers, periodicallydetermining a pre-fetch score based on pre-fetch factors comprising thehistorical client latency, the scheduled backup server workload, andfailure percentage; and in response to determining that the pre-fetchscore does not exceed a maximum threshold on each of the plurality ofbackup servers, pre-fetching metadata on a backup server having a lowestpre-fetch score.
 16. The method of claim 13, wherein the metadata ispre-fetched from a metadata repository to metadata cache.
 17. The methodof claim 13, wherein the second backup server provides a client with alist of backup severs for use for future requests.
 18. The method ofclaim 13, wherein the plurality of backup servers are nodes in a cloudinfrastructure that includes a metadata cache for each of the pluralityof backup servers, backup data storage for each of the plurality ofbackup servers, metadata repositories shared by each of the plurality ofbackup servers, and common storage shared by each of the plurality ofbackup servers.